uefi: fs: Add file times plumbing #138918

Ayush1325 · 2025-03-25T03:03:32Z

Add plumbing to allow conversions to and from UEFI Time to Rust SystemTime.
Also add FileTimes implementation.

petrochenkov · 2025-03-25T15:12:53Z

(I'll initially mark these PRs as waiting on author in the sense that, that they are waiting for the author to summon @nicholasbishop and get a review. It can be marked as ready when there's a review.)
@rustbot author

library/std/src/sys/pal/uefi/time.rs

Ayush1325 · 2025-04-11T19:55:36Z

@rustbot label +O-UEFI

joboet

I'm a bit worried about the edge cases here. It's not that uncommon to end up with a system time of 1970-1-1 if the devices clock is uninitialised. If the current timezone is positive, this might lead to a panic when converting it to a UNIX time. Considering the insanely large bounds afforded by secs being 64-bit, using a signed integer in the conversion algorithm would allow converting dates before the UNIX epoch as well.

Aside from that, the checked methods on SystemTime operate on the assumption that the operation will fail if the time is not representable in the operating system format – but this is currently not the case: UEFI allows times from the year 1900 up to and including the year 9999, whereas a Duration since the UNIX epoch allows representing times from 1970 up to the heat death of the universe, but not before that. I think it would be better to use the UEFI time representation for SystemTime and only convert it into a Duration for the addition/subtraction operations.

joboet · 2025-04-13T14:03:11Z

library/std/src/sys/pal/uefi/time.rs

+        let secs = if timezone == r_efi::efi::UNSPECIFIED_TIMEZONE {
+            dur.as_secs()
+        } else {
+            dur.as_secs().checked_add_signed(-timezone as i64).unwrap()


I'd use subtraction here, just like the formula in the UEFI spec.

Suggested change

dur.as_secs().checked_add_signed(-timezone as i64).unwrap()

dur.as_secs().checked_sub_signed(timezone as i64).expect("times should be representable as local UEFI times")

checked_sub_signed is currently unstable. I can add the feature if that is fine though.

joboet · 2025-04-13T14:03:49Z

library/std/src/sys/pal/uefi/time.rs

+        let remaining_secs = secs % SECS_IN_DAY;
+        let z = days + 719468;
+        let era = z / 146097;
+        let doe = z - (era * 146097);


This is clear by operator precedence, and the source doesn't use parenthesis here either.

Suggested change

let doe = z - (era * 146097);

let doe = z - era * 146097;

Ayush1325 · 2025-04-13T14:31:39Z

I'm a bit worried about the edge cases here. It's not that uncommon to end up with a system time of 1970-1-1 if the devices clock is uninitialised. If the current timezone is positive, this might lead to a panic when converting it to a UNIX time. Considering the insanely large bounds afforded by secs being 64-bit, using a signed integer in the conversion algorithm would allow converting dates before the UNIX epoch as well.

Aside from that, the checked methods on SystemTime operate on the assumption that the operation will fail if the time is not representable in the operating system format – but this is currently not the case: UEFI allows times from the year 1900 up to and including the year 9999, whereas a Duration since the UNIX epoch allows representing times from 1970 up to the heat death of the universe, but not before that. I think it would be better to use the UEFI time representation for SystemTime and only convert it into a Duration for the addition/subtraction operations.

Yes, I did come to the same conclusion. I think the reason I initially went with duration was to have a simple implementation for all the function implemented on SystemTime (since all the results there are in Duration). I will try representing SystemTime using UEFI Time internally and see how it looks.

bors · 2025-08-12T16:39:00Z

☔ The latest upstream changes (presumably #145300) made this pull request unmergeable. Please resolve the merge conflicts.

Ayush1325 · 2025-08-12T18:25:33Z

@rustbot ready

ping @nicholasbishop @joboet

petrochenkov · 2025-08-12T18:29:37Z

r? @joboet

nicholasbishop · 2025-08-12T18:36:00Z

library/std/src/sys/fs/uefi.rs

@@ -32,8 +48,11 @@ pub struct OpenOptions {
    create_new: bool,
 }

-#[derive(Copy, Clone, Debug, Default)]
-pub struct FileTimes {}
+#[derive(Copy, Clone, Debug)]


Time implements Default, so can't we keep deriving Default here and remove ZERO_TIME?

joboet · 2025-08-13T14:44:21Z

library/std/src/sys/fs/uefi.rs

-    pub fn set_modified(&mut self, _t: SystemTime) {}
+    pub fn set_accessed(&mut self, t: SystemTime) {
+        self.accessed =
+            t.to_uefi(self.accessed.timezone, self.accessed.daylight).expect("Invalid Time");


Can we avoid this panic? As the SystemTime was created successfully (i.e. checked_add did not return an error), this panic will come as a surprise to users.

A better way perhaps would be to try the initial timezone first, and if that fails, return the closest timezone (minute offset) that still allows the time to be represented. If filesystems ignore the timezone field, this would lead to the first and last 1440 minutes being collapsed into one minute, which doesn't seem too bad.

I have added the appropriate helpers to use the closest timezone. I have also added the tests that I have used locally to check the new timezone.

nicholasbishop

uefi lgtm

View changes since this review

nicholasbishop · 2025-08-26T16:29:54Z

library/std/src/sys/pal/uefi/time.rs

        system_time_internal::to_uefi(&self.0, timezone, daylight)
    }

+    /// Create UEFI Time with the closes timezone (minute offset) that still allows the time to be


Suggested change

/// Create UEFI Time with the closes timezone (minute offset) that still allows the time to be

/// Create UEFI Time with the closest timezone (minute offset) that still allows the time to be

beetrees

Thanks for working on this.

View changes since this review

beetrees · 2025-08-26T21:35:27Z

library/std/src/sys/fs/uefi.rs

@@ -18,6 +18,8 @@ pub struct File(!);
 pub struct FileAttr {
    attr: u64,
    size: u64,
+    created: r_efi::efi::Time,


UEFI allows creation time to be set, so created should be part of the FileTimes struct (a future PR can then use it to implement set_created in an extension trait like on Windows and Apple platforms).

beetrees · 2025-08-26T21:51:23Z

library/std/src/sys/fs/uefi.rs

-    pub fn set_accessed(&mut self, _t: SystemTime) {}
-    pub fn set_modified(&mut self, _t: SystemTime) {}
+    pub fn set_accessed(&mut self, t: SystemTime) {
+        self.accessed = t.to_uefi_loose(self.accessed.timezone, self.accessed.daylight);


.timezone and .daylight will always be zero here (unless set_accessed/set_modified was called previously and that time had to have it's timezone adjusted to fit in the range of EFI_TIME). The EDK II FAT driver will ignore the timezone when setting the time.. As FAT stores timestamps in the system local time, this conversion should use the current system timezone from the runtime services GetTime in order to be compatible with that driver's behaviour. This conversion should be done in the File::set_times implementation to have consistent behaviour in the (unlikely) event the timezone is changed between the call to set_accessed and the actual setting of the file times in File::set_times (which I believe isn't being implemented in this PR); therefore the FileTimes struct should look something like struct FileTimes { accessed: SystemTime, modified: SystemTime, created: SystemTime }.

I have converted all FileTimes members to be SystemTime.

beetrees · 2025-08-26T21:51:27Z

library/std/src/sys/fs/uefi.rs

@@ -60,15 +65,15 @@ impl FileAttr {
    }

    pub fn modified(&self) -> io::Result<SystemTime> {
-        unsupported()
+        Ok(SystemTime::from_uefi(self.times.modified))


FAT timestamps are always stored in local time in the system timezone, and the EDK II FAT driver uses EFI_UNSPECIFIED_TIMEZONE to represent this. Therefore, if the modified/accessed/created EFI time has a timezone of unspecified, this conversion should use the timezone from the runtime services GetTime in order to be compatible.

Since this PR does not have any boundary code, I have added helper uefi_to_systemtime that uses the timezone from current time in unspecified timezone cases.
When converting back to UEFI time, I am also using local timezone now in the helper systemtime_to_uefi

All these helpers are local fs since we do not know if some other subsystem might want to handle these specific cases differently.

- Add FileTimes implementation. Signed-off-by: Ayush Singh <[email protected]>

rustbot assigned petrochenkov Mar 25, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 25, 2025

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 25, 2025

beetrees reviewed Mar 25, 2025

View reviewed changes

library/std/src/sys/pal/uefi/time.rs Outdated Show resolved Hide resolved

Ayush1325 force-pushed the uefi-fs-time branch from 394434c to 4c497b4 Compare March 30, 2025 17:11

Ayush1325 mentioned this pull request Apr 2, 2025

Tracking Issue for uefi-std #100499

Open

rustbot added the O-UEFI UEFI label Apr 11, 2025

joboet reviewed Apr 13, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from 4c497b4 to 48330eb Compare August 12, 2025 16:43

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 12, 2025

rustbot assigned joboet and unassigned petrochenkov Aug 12, 2025

nicholasbishop reviewed Aug 12, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from 48330eb to e21995b Compare August 12, 2025 18:38

joboet reviewed Aug 13, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from e21995b to 6637ec8 Compare August 13, 2025 16:49

Ayush1325 requested review from joboet and nicholasbishop August 16, 2025 06:36

nicholasbishop approved these changes Aug 26, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from 6637ec8 to 0632fd5 Compare August 26, 2025 17:24

beetrees suggested changes Aug 26, 2025

View reviewed changes

uefi: fs: Add file times plumbing

fc63980

- Add FileTimes implementation. Signed-off-by: Ayush Singh <[email protected]>

Ayush1325 force-pushed the uefi-fs-time branch from 0632fd5 to fc63980 Compare August 27, 2025 06:51

	dur.as_secs().checked_add_signed(-timezone as i64).unwrap()
	dur.as_secs().checked_sub_signed(timezone as i64).expect("times should be representable as local UEFI times")

	/// Create UEFI Time with the closes timezone (minute offset) that still allows the time to be
	/// Create UEFI Time with the closest timezone (minute offset) that still allows the time to be

uefi: fs: Add file times plumbing #138918

Are you sure you want to change the base?

uefi: fs: Add file times plumbing #138918

Conversation

Ayush1325 commented Mar 25, 2025

Uh oh!

petrochenkov commented Mar 25, 2025

Uh oh!

Uh oh!

Ayush1325 commented Apr 11, 2025

Uh oh!

joboet left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ayush1325 commented Apr 13, 2025

Uh oh!

bors commented Aug 12, 2025

Uh oh!

Ayush1325 commented Aug 12, 2025

Uh oh!

petrochenkov commented Aug 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nicholasbishop left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

beetrees left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nicholasbishop left a comment •

edited by rustbot

Loading

beetrees left a comment •

edited by rustbot

Loading